With the rise of interconnected computer networks such as intranets and the Internet, complex transaction-based applications that are distributed over several networked computers became a possibility. In general, these transaction-based applications function in the following way. A software application program, which executes on a computer called a client, initiates a transaction that requires access to services provided by a distant computer, called a server. Examples of these services could be an update to a database such as a bank's database, execution of a purchase order such as in the case of purchase of a security, and the like. Typically, the client sends a “request” message to the server, which then sends a “response” message containing a response to the request.
Assume that the server is not a single computer, and instead, a collection of interconnected heterogeneous computers. The request message must then be formatted in such a way that all the interconnected computers can understand and respond to the request message. This is generally the case where a client coordinates a distributed transaction, as is the case in a typical client-server model. If the collection of interconnected computers is configured in an object-oriented programming model, then software objects (or objects) that are capable of working together to provide a response to the request message can be distributed among the several computers. But in order to access the objects from a remote computer such as a client, the objects must somehow publish their existence, their addresses, their properties, the services they provide, and other details to the “outside” world. Then, a client may be able to use the services provided by sending a request message in a manner similar to making a remote procedure call (“rpc”) and obtaining a response to that message.
Three paradigms arose as a result of the need to standardize the methods by which objects could be distributed and accessed over a network. These are Microsoft Corporation's Distributed Component Object Model (DCOM), JavaSoft's Java/Remote Method Invocation (Java/RMI), and Object Management Group's Common Object Request Broker Architecture (CORBA).
Though differences exist among these models, they principally work in the following way. Objects that provide services are typically located on servers. These objects are queried by applications running on clients using a specified data communication transport layer protocol-the Object Remote Procedure Call (ORPC) for DCOM; the Java Remote Method Protocol (JRMP) for Java/RMI; and the Internet Inter-ORB Protocol (IIOP) for CORBA. A client suitably formats a query message in the appropriate protocol language and transmits the query message, which is routed to the appropriate server, whereupon it is examined, and a response message is formatted and routed back to the client.
As used in the present application, the term “object” may mean the object definition, associated operations, attributes, as well as the implementation for that object. Persons of ordinary skill in the art understand that the term “object type” is used to refer to the definition of the operations and attributes that software external to the object may use to examine and operate upon the object. An object of a given type can support multiple interfaces. Additionally, the term “object” may sometimes be used to refer to an actual run-time instance of an object and will be made clear by the context.
As stated above, clients should be configured to understand the services offered by the various objects located at the servers. In DCOM, this is achieved by exposing certain methods of a DCOM server. In this paradigm, a client acquires an interface pointer to one of the server's exposed methods. This interface pointer presents itself to be locally addressable to the client. An object at the client—for example, a proxy object—uses the interface pointer and calls the server's methods in order to determine their structure and properties.
In Java/RMI, objects are encoded and transmitted (“marshaled”) in streams of bytes by a process called “serialization.” A server configured to be a Java/RMI server comprises objects that have predefined interfaces, which can be used to access the server objects remotely from another machine's Java Virtual Machine (JVM). A Java/RMI server object interfaces declare a set of methods that indicate the services offered by that server object. A program resident on the server called an RMI Registry stores and makes available to clients information about available server objects. Typically, a client object obtains information regarding the methods and other properties of a server object by performing an operation such as “lookup” for a server object reference. This lookup typically works by the client object specifying an address in the form of a Universal Resource Locator (URL) and transmitting the address to the server's RMI Registry.
During the early 1990s, there had been a shift from a two-tier, client-server application model to a more flexible architecture that incorporated modular separation of concerns. This resulted in breaking the application model to include a three or more-tier models, which separated business logic from system services and user interfaces. The business logic is placed in a different layer-frequently called the middle-tier or middleware- and included transaction monitoring, messaging, object request brokering, and other services. This also allowed the deployment of lightweight clients that are easy to deploy.
In general, these architectures are thought to simplify developing, deploying, and maintaining enterprise applications. The cited advantages for this architecture included a focus on the specifics of business logic programming without the need for transaction management and user-interface considerations. Thus, the multi-tier architecture enabled developers to focus on the specifics of programming their business logic, relying on various back-end services to provide the infrastructure, and client-side applications (both standalone and within web browsers) to provide the user interaction. Because of the logical separation achieved by the multi-tier model, business logic can be developed once and deployed on servers appropriate to the needs of an organization in such a way that the servers can be readily scaled to meet changing business conditions.
While the above methods are directed toward distributing the objects over a collection of networked computers, there still was a need to develop a standardized way to develop transaction-oriented systems that are vendor-independent. Traditionally, products such as TUXEDO™, CICS™, have been used to provide transaction management, security, concurrence, persistence and other services in transaction-oriented applications such as travel planning, banking and stock market transactions. But there was a problem of integrating these products with the newly emerging distributed object computing models discussed above. Additionally, it was determined that transaction-related programming logic should advantageously be separated from business logic. The middle tier, i.e., the layer between the client and the “back-end,” is therefore modeled so that transaction monitors are separated from programming entities that perform only the business logic. It should be noted that the transaction monitors are infrastructure components insofar as they are a part of application server architecture. Transaction monitors need not be implemented as objects.
This need for a standardization resulted in the Enterprise JavaBean™ (EJB) computing model, which took advantage of the technological advances such as the JDBC technology. The servlet technology enabled developers to create CGI-like behaviors that could run on any web server that supported the Java platform. The JDBC™ technology provided a model for integrating the “Write Once, Run Anywhere™” features of the Java programming language to existing database management systems. And the JavaBeans component architecture enabled encapsulation of complete sets of behavior into easily configurable, readily reusable components on the client side. The convergence of these three concepts-server-side behaviors written in the Java programming language, connectors to enable access to existing enterprise systems, and modular, easy to deploy components-led to the development of the EJB standard. It should be noted that the Enterprise JavaBeans might be used in conjunction with any of the technologies described herein.
In the discussion that follows, a reference to a “bean” indicates it is an Enterprise JavaBean or a similar component. Additionally, an “application server,” a “middleware server,” an “enterprise application server,” or a “server” are terms used interchangeably unless otherwise qualified, each of which terms indicates a computer connected to a communication network and at least one of a plurality of back-end computers or data repositories, for example, a legacy database server.
The EJB is a server-side component model that incorporates the business logic in software components called beans. An enterprise application server or simply, a “server” that is configured as an EJB server is responsible for managing services such as transactions, persistence, concurrence and security.
The EJB architecture, which is a distributed object architecture, comprises one or more computers configured as EJB server(s), EJB container(s) that run within the EJB server(s), beans that execute within these containers, and EJB clients. EJB clients locate beans using an interface called the Java Naming and Directory Interface (JNDI); and utilize transaction support services such as Java Transaction Service (JTS). Typically, the beans are similar to the server objects described above, except that they contain only business and no transaction-monitoring logic. EJB servers provide certain predefined system services such as raw execution environment, multiprocessing, load balancing, access to devices, naming and translation service provisioning, and making EJB containers visible. EJB containers provide the interface between the EJBs and EJB clients. In general, an EJB client can access a bean only via EJB container-provided methods, which in turn invoke the bean's methods.
An EJB object is a “remote” interface object that implements the remote interface of a bean. It wraps a bean instance on the server and expands its functionality to include transactions, security and other system-level operations to the bean at runtime. Typically, an EJB container vendor provides the utilities to create the EJB object.
Similar to the EJB object class, the EJB home class is also automatically created when an Enterprise JavaBean is installed in a container. The EJB home class implements all the methods defined by the bean's home interface and is responsible for helping the container manage the bean's life cycle. The EJB home is responsible for locating, creating and removing enterprise beans, by working with the EJB Server's resource managers, instance pooling, and persistence mechanisms as needed transparently to the developer.
In the EJB model, there are two types of beans-session beans and entity beans. Session beans, as their name indicates, are used to keep track of and manage a client's session with the server. A session bean is usually associated with a single EJB client. In general, session beans do not survive a server shutdown or crash. Session beans can preserve their states through a user's session lifetime.
A stateful session bean contains state information. Typically, when a client initiates a connection with the server, the client specifies the type of EJB to which it connects on the server. When the client is finished with the session, the stateful session bean is typically removed. Thus, in a typical scenario, only one client can use an instance of a particular stateful session bean at a given time.
A stateless session bean instance is an object that can be reused by different clients, one at a time. Since it can be reused, a stateless session bean instance need not be destroyed until all clients are finished with them. Additionally, it contains no state information, and therefore, it is impossible for the client to tell one stateless session bean from another of the same type. Thus, one stateless session bean of a particular type is virtually indistinguishable from another of the same type. In view of these properties, stateless session beans of each type are pre-created by an EJB container in sufficient numbers and placed together in pools of stateless beans. Whenever a client requests a stateless bean of a certain type, a bean of that type is removed from the proper pool and given to the client. Once the client is done, the bean is returned to the pool. These beans are only created and/or deleted by the EJB container itself.
Multiple EJB clients, on the other hand, can share entity beans. They always have states and these states persist server shutdown or crash. Typically, these are implemented by writing any state-related data into a persistent store so that the bean can be reconstructed from the stored data after a server is restarted subsequent to a shutdown or a crash.
An entity bean instance is usually associated with a specific row (record) in a specific table. More complex mappings are also possible. An entity bean is also associated with a transaction. The bean's state is always in step with the transaction—if the transaction commits, the bean's state persists, and if the transaction rolls back, the bean is brought back to its initial state. This synchronization is automatic and seamless to a developer, unless the bean is deployed as having bean-managed persistence, or no transactional persistence at all. In general, a client can access a particular entity bean instance using an identifier or a key.